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[57] ABSTRACT 

A client workstation generates a network request for an 
initial program load. The request is serviced by a server 
which preferably includes in the reply to the client the 
addresses of an authentication server (AS), client, and a 
secure initial program load server (SECIPL). The client 
then requests an SECIPL service ticket from the AS, 
also sending a common identifier known to the AS and 
the client, preferably stored in the client ROM. This 
identifier is utilized by the AS to validate the ticket 
request as originating from a bona fide client, where- 
upon the ticket is provided by the AS to the client, the 
SECIPL service ticket is then presented by the client to 
the SECIPL server which then authenticates that the 
ticket is bona fide and was received by the client from 
the AS. The SECIPL then provides a secure kernel to 
the client, either encrypted with a key known to the 
SECIPL and client, or otherwise secured by a crypto- 
graphic checksum utilizing a key known to the client 
and the SECIPL. In this manner, the client workstation 
is thereby assured that an authenticated boot image has 
been received through potentially non-secure commu- 
nication links. 

24 Claims, 3 Drawing Sheets 
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SYSTEM AND METHOD FOR SECURE INITIAL 
PROGRAM LOAD FOR DISKLESS 
WORKSTATIONS 

5 

FIELD OF THE INVENTION 

This invention relates to computer networks in gen- 
eral and, more particularly, concerns systems and meth- 
ods for ensuring a secure boot for a diskless worksta- 
tion. 10 

BACKGROUND OF THE INVENTION 

Computer networks are quite prevalent in the art 
now which provide for one or more server machines 
interconnected in a network fashion to multiple client 15 
machines generally of lesser capability. There are nu- 
merous benefits to this arrangement. For example un- 
necessary replication of more expensive hardware at the 
clients is avoided which might otherwise be shared by 
multiple clients if located at a central repository. 20 

In such networks, it is common to provide the client 
machines in the form of medialess or diskless worksta- 
tions. These machines have no substantial (and gener- 
ally more expensive) non-volatile mass storage devices 
such as DASD or the like. Rather, they rely upon mass 25 
storage devices such as at servers at other locations in 
the network to store the necessary code and data which 
must be available to the client machines to perform their 
functions. In such arrangements, it is conventional for 
the server(s) to deliver the code and data over the net- 30 
work connection to the particular client at appropriate 
times. In this manner, the client need only have present 
in its real memory at any given time only the informa- 
tion stored in the mass storage devices at the server(s) 
necessary to perform a function at that time. The need 35 
is thereby avoided of having mass storage devices at 
each client containing information which remains in an 
unused state for long periods of time and which adds to 
the cost of the network. 

Representative such client-server systems may be 40 
seen described in U.S. Pat. No. 5,056,140 entitled 
"Communication Security Accessing System and Pro- 
cess" and U.S. Pat. No. 4,958,278 entitled "Method for 
Loading Data or Program to a Plurality of Terminal 
Stations", for example. 45 

Several problems have come about as a result of the 
growth of these computer network systems. Not the 
least of these is the serious problem of unauthorized 
access to the systems which has been reported with 
alarming increased frequency. With the proliferation of 50 
large multi-user computer systems with enormous 
banks of extremely valuable data, techniques were 
highly sought for enhancing the security of these net- 
works. 

Accordingly, numerous schemes have developed 55 
over the years including encryption, passwords, physi- 
cal security devices such as keyed switches, and so forth 
in an effort to deter the rising rates of unauthorized 
access. Several subtle security exposures arise from the 
characteristics of the diskless workstation in seeking to 60 
secure the previously described network systems which 
employ diskless workstations. As but one example, in 
order for such a workstation to become operative upon 
power up, it is necessary for the workstation to obtain 
the kernel operating system code from somewhere else 65 
in the network. This is because the operating system is 
not resident at the workstation itself (for reasons previ- 
ously described that the non-volatile storage necessary 
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to store the operating system at the workstation is unde- 
sirable and cost-prohibitive.) One problem with this, 
however, is that the industry standard boot protocol 
does not provide for certification of this kernel code 
delivered from the network to the booting diskless 
workstation in any way. 

The delivery of non-certified boot code to a worksta- 
tion upon booting is fraught with numerous problems 
which have beset the industry, particularly in the more 
security-sensitive areas in which computer networks 
have been established. As but one example, one of the 
computers in the network could be configured to pro- 
vide a kernel to a diskless system when it boots. It may 
be assumed, for purposes of illustration, that this kernel- 
providing system may be faster at providing such kernel 
code than the "officially" designated kernel source 
machine for the network. In such a case, upon booting 
of the diskless workstation, the non-certified kernel 
from the computer will be loaded by the workstations 
which then, in response, might very typically be asked 
to supply a password. Upon the password being pro- 
vided by the operator at the workstation, this password 
would be received by the computer providing the 
bogus boot kernel code requested by the workstation. 
Later, the unauthorized individual, who has thereby 
surreptitiously obtained the valid password from the 
workstation operator, could sign onto the network sys- 
tem, utilize the thus-obtained valid password, and unau- 
thorizedly enter the entire computer network. 

In an effort to solve the foregoing problems, numer- 
ous solutions were attempted resulting in customer 
requirements for diskless stations, networks and modifi- 
cations which were not appropriate or cost-effective for 
systems not requiring such security. This resulted in 
manufacturing expenses and costs associated with pro- 
viding two types of systems. 

Accordingly, systems and methods were needed 
which could provide assurances that a diskless worksta- 
tion was obtaining a certified kernel upon booting, and 
which could further ensure the kernel server that the 
workstation machine requesting the kernel was an au- 
thorized workstation. 

It was accordingly an object of the invention to pro- 
vide an improved boot architecture. 

Yet another object of the invention is thus to provide 
an improved communication security system for disk- 
less workstations which rejects connection to an unau- 
thorized user terminal. 

Still another object was to provide for a boot archi- 
tecture for secure initial program load (IPL) for diskless 
workstations which nevertheless provided the ability to 
offer one standard diskless station with only minimal 
modifications being required for the addition of a secure 
IPL feature. 

These and other objects and features are provided by 
the invention, a fuller understanding of which may be 
obtained with reference to the following description 
taken in connection with the accompanying drawings, 
wherein: 

SUMMARY OF THE INVENTION 

A client workstation generates a network request for 
initial load information. The request is serviced by a 
server which preferably includes in the reply to the 
client the addresses of an authentication server (AS), 
client, and a secure initial program load server (SE- 
CIPL). Additionally, the reply will typically include 
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the client realm, client principal name and time of day, 
although the latter two may optionally be provided 
other servers whose names are provided in the bootp 
response or otherwise available to the client in hard- 
ware. The client then requests an SECIPL service 
ticket from the AS, also sending a common identifier 
known to the AS and the client, preferably stored in the 
client ROM. This identifier may be the principal name 
of the SECIPL utilized by the AS to validate the ticket 
request as originating from a bona fide client. The ticket 
is then provided by the AS to the client after the AS 
authenticates the client by means of checking the com- 
mon identifier. The SECIPL service ticket thereby 
received by the client from the AS is then presented by 
the client to the SECIPL server. The SECIPL server 
then authenticates that the ticket provided by the client 
to the SECIPL is bona fide and was received by the 
client from the AS, in that the SECIPL has knowledge 
of the content of an authentic ticket originating from 



10 



15 



contain more limited storage 20 for storing the neces- 
sary IPL and kernel code 18 which is downloaded 
through the server 10 and the LAN 14 when the partic- 
ular workstation is booted: This storage 20 is typically 
in the form of volatile random access memory which is 
relatively inexpensive. It however has the unfortunate 
characteristic that upon power down the data stored 
therein is destroyed, thus requiring repeated download 
of the code 18 from the server 10 upon each such in- 
stance of booting of a workstation. The workstations 
may, in some instances however, have non-volatile 
storage and the invention is thus not intended to be 
limited only to diskless workstations. 

It will be noted in passing that these workstations also 
typically contain a small amount of non-volatile storage 
capacity normally in the form of read only memory 
(ROM). This ROM contains the essential code perform- 
ing the very limited function of initiating the download 
procedure of the more extensive boot IPL and kernel 



the AS. The SECIPL then provides a secure kernel to 20 operating system code which will thereafter be used by 



the client, either encrypted with a key known to the 
SECIPL and client, or otherwise secured by a crypto- 
graphic checksum utilizing a key known to the client 
and the SECIPL. In this manner, the client workstation 
is thereby assured that an authenticated boot image has 25 
been received through potentially non-secure commu- 
nication. 



the particular workstation in performing its normal 
functions. 

Turning now to the diagram of the network shown in 
FIG. 2, the features of the present invention will now be 
described providing for delivery of a secure initial pro- 
gram load of this code 18 for such workstations. First 
the components of FIG. 2 and a high level explanation 
of their functions will be described with reference to 
FIG. 2 followed by a detailed description of the se- 
FIG. 1 is a functional diagram of a conventional com- 30 quence of operation of the invention with reference to 
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puter client-server network utilizing diskless worksta- 
tions; 

FIG. 2 is a more detailed functional block diagram of 
a networking system of FIG. 1 utilizing the secure IPL 
process in accordance with the invention; and 

FIGS. 3A and 3B is a flow diagram representing the 
sequence of process steps in accordance with the inven- 
tion providing a secure IPL for diskless workstations in 
a computer networking environment. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

Referring first to FIG. 1, a conventional computer 
network is shown typically comprised of a server sta- 
tion 10 ("server"), and a plurality of terminal stations or 45 
workstations also known as "clients" 12A-12N inter- 
connected by means of a local area network or LAN 14. 
The server station 10 includes a mass storage unit 16 
known as a direct access storage device (DASD). 

One of the desirable characteristics of the client- 50 
server type networks shown in FIG. 1 stems from the 
fact that in such networks it may be common to have 
large numbers of such workstations distributed 
throughout a work environment. Accordingly it is 
highly desirable to keep the cost of such workstations 55 
low and avoid unnecessary duplication of hardware 
which might better and more efficiently be imple- 
mented at a central location such as at the server. One 
such opportunity arises from the fact that there is com- 
mon code and data which typically must be utilized by 60 
all of the workstations 12A-12N upon initial boot up 
procedures as well as common operating system code 
enabling the workstations to perform their normal work 
functions. 

This initial program load (IPL) and kernel code 18 65 
may thus advantageously be stored in the DASD 16 and 
then accessed as necessary in a boot sequence by the 
workstations 12 A-12N. These workstations will in fact- 



the flow diagram of FIG. 3. 

There is shown in FIG. 2 a plurality of client work- 
stations 20 similar to the workstations 12A-12N of FIG. 
1. Additionally, the system of FIG. 2 typically includes 
a secure IPL server 28, which serves the purpose of 
providing the program images required for IPL by the 
client workstations 20. 

Additionally, the system of FIG. 2 will typically 
include an authentication server such as Kerberos 
server 24, which serves the purpose of ensuring that 
upon initial contact with the AS, each workstation cli- 
ent 20 is verified to be genuine and further responsible 
for providing authentication keys for continued opera- 
tion. Although the embodiment depicted employs a 
Kerberos authentication system well known in the art, 
the invention is not intended to be limited to such a 
particular implementation of a security system. 

Also, the system of FIG. 2 will desirably include a 
bootp server 44 which serves the function of responding 
to client bootp requests to provide information which 
allows the clients to continue with the boot process. 
The foregoing generally described functional elements 
of the system FIG. 2, it will be appreciated, may be 
implemented on multiple physical machines or on a 
single machine as the application dictates. 

The workstations 20 function through a LAN 21 
functionally represented by the arrows in connection 
with various servers to be hereinafter described and 
mass storage 23 broadly in a manner similar to that of 
FIG. 1. However, with respect to the system and 
method of the invention, the client workstations 20 
access some minimal information utilized to implement 
the desired authentication service of the invention 
whereby the kernel and client boot sequence may 
thereby be certified or authenticated. This information 
shown in FIGS. 3A and 3B includes a first service key 
22 for each workstation to be hereinafter described 
known only to the client workstations 20 and the Ker- 
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beros Authentication Server (AS) 24. Further such server, where the IP address of the nameserver was 

information includes the principal name 26 of the secure provided in the BOOTP response. The current time of 

kernel IPL service (SECIPL) 28 and the client's day 34, in like manner may be acquired by querying a 

REALM name 30. A realm name is a concept of secu- local time server where the IP address of the timeserver 

rity systems whereby a client is assigned a realm name 5 could be provided also in the BOOTP response. Both or 

utilized by a security server 24. The client to instruct either of these pieces of information may be cached 

the client 20 as to which security server 24 the client is locally or derived in some implementation-specific way 

to communicate with to validate information. Still fur- as desired. The other four items of information (namely 

ther such information desirably includes the current the IP addresses 36-40 and the name 30 of the client 20 

time of day 34 within a REALM-specific skew value 10 realm) will desirably be presented in the BOOTP re- 

which may be provided by a bootp server 44, the princi- sponse to the client. The realm name 30 of the client 20 

pal name 32 of the client 20 (also provided by the bootp in one implementation may be up to 128 bytes long, it 

server 44), the IP address 36 of the client 20, the IP further being preferred that the BOOTP response for 

address 38 of the authentication server 24, and the IP the desired secure IPL include the realm name 30 of the 

address 40 of the SECIPL server 28. 15 client 20. 

It is desirable for the ROM 42 of each client 20 to A more detailed description will now be provided 

contain the previously noted principal name 26 of the with reference to FIGS. 3 A and 3B of the formats of the 

SECIPL server or service 28. The client 20 as previ- Kerberos packets that should be understood by the 

ously noted is also responsible for knowing the secret BOOTP client 20. In a preferred implementation there 

first key 22 to be hereinafter described. The BOOTP 20 are four basic packets 66 which are exchanged by the 

server 44 is provided which may provide the aforemen- client 20 as follows: 

tioned principal name of the client itself, 32, and the KRB_AS_REQ, 68, is a packet sent from the client 

current time of day 34. The BOOTP server 44 will 20 to the Kerberos server 24 to obtain a ticket 48 to later 

desirably also provide the just-described client's realm present to the SECIPL service 28. 

name 30, and the IP addresses 36-40 of the clients, the 25 KRB— AS—REP, 70, is a packet response from the 

AS server and the SECIPL, respectively. Kerberos server 24 to the KRB_AS_REQ request in 

The confidential first key 22 is preferably only known packet 68 and will contain the ticket 48 for the SECIPL 

by the client workstation's 20 and the AS server 24 (as service 28. 

well as, of course, a system network administrator, KRB_AP_REQ, 72, is a packet sent from a particu- 

security personnel, or the like, etc.). Regarding imple- 30 lar client 20 to the SECIPL service 28 to request an IPL 

mentation of the key 22 on the client side of the net- kernel 70, which also contains the shared second key 71 

work, in one implementation an external security device to be used for optional kernel encryption or crypto- 

46 such as a keyed lock may be physically attached to graphic checksum. 

the client workstation's 20 in order to provide the key KRB_AP_ REP, 74, is a packet containing a re- 
22. It will be noted that the key 22 utilized by the client 35 sponse from the SECIPL server 28 to the KRB— AP_ 
workstation's 20 preferably will not be used anywhere REQ request 72. There are provided in this packet the 
else. Such a key 22 is to be distinguished from a key fields 75 and 73 which are part of the request packet and 
typically utilized by an individual signing onto a work- would preferably be encrypted, thereby requiring de- 
station 20 which is utilized to validate the user to the cryption by the client 20 utilizing the shared second key 
server 24. It will further be noted that the key 22 in the 40 71 to authenticate the SECIPL server 28. 
preferred implementation will be utilized only once, The KRB— AS— REQ and KRB-AS-REP packets, 
whereby such a key 22 will be employed to request 68 and 70, respectively, will be sent as standalone pack- 
from the AS server 24 a ticket 48 to the SECIPL ser- ets to and from the Kerberos server 24 identified in the 
vice 28. Conventionally the AS server 24 would nor- BOOTP response 58. The KRB_AS_REP packet 70 
mally provide a ticket to a Ticket Granting Service 45 contents from the AS 24 will be checked with the first 
(TGS) which itself performs the action function of pro- key 22 by client 20 to verify the Kerberos server or 24 
viding a key 22. AS is a valid one. It should be apparent that only a valid 
As noted before, the principal name 26 of the SE- Kerberos server 24 will contain the unique secret key 22 
CIPL service 28 in a preferred embodiment is to be of a particular client workstation 20. A ticket field 48 
hard-coded into the ROM 42 of each client workstation 50 from the KRB— AS— REP packet 70 will be placed in 
20. This is to prevent an attack on the security of the the KRB—AP— REQ packet 72 to present to the SE- 
network described hereinbefore in the Background of CIPL server 28. The whole KRB^AP_REQ packet 72 
the Invention wherein an export of a valid service may will be preferably included in a TFTP RRQ packet 
create a counterfeit BOOTP server which could re- directly behind the SECIPL option. (A modified 
spond more quickly than the bonafide real BOOTP 55 TFTPB daemon is provided which will return a 
service 44. This counterfeit BOOTP server could KRB— AP— REP packet 74 before starting the desired 
thereby present the IP address and service name of a file transfer). 

counterfeit IPL server. The client 20 in such an attempt Turning for a moment to a more detailed description 

at a security breach, would authenticate normally, and of the SECIPL server 28, in a preferred implementation 

the resulting bits received from the counterfeit SECIPL 60 this SECIPL server 28 is a modified TFTPD server, 

server could thereby be utilized to attack the security of such modification essentially being that the server sup- 

the network effecting a serious security breach. ports services for selection of IPL images based on 

Two items of optional information in the implements- supplied criteria from the client and that this modified 

tion being described with reference to FIG. 3 presented server will return the KRB— AP-REP packet prior to 

by the BOOTP server 44 to the client 20 must be de- 65 beginning file transfer to the client. The server 28 may 

rived by the workstation 20 if they are not provided in preferably be included as part of the BOOTP server 44, 

the BOOTP response. The principal name 32 of the or alternatively may be stand alone. The SECIPL 

client 20 may be derived by querying a local name- server 28 will accept the hereinbefore described RRQ 
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packet along with information on the state of the key tion device, and removable key or keys, the customer 

switch of the client, client processor type, main memory would thereby be charged for the associated cost of 

size, and the client's principal name 32. The server 28 level of security which might not be necessary for other 

will then select a kernel based upon this information to customers. 

return to the client 20. Trie kernel data itself may desir- 5 One problem associated with standard security ap- 

ably be encrypted with the shared session key 48 to be proaches such as a Kerberos system, is that in standard 

further described or the service may append a crypto- Kerberos technology a principal name is made up of 

graphic checksum at the end of the kernel transfer. two parts: the service name, and an "instance" name. 

Still referring to FIGS. 3A and 3B, the KRB—AS — The principal name 26 of the SECIPL service would 
REP doubly-encrypted ticket will contain the ticket 10 accordingly be treated as a constant. There is no in- 
field 48 encrypted by the key Kl, reference numeral 22, stance-specific component of the principal name. This 
as well as the key K2, 71, the first key 1 being known by further would norma ii y be required because the client 

°i™ a £ d ^L and k L ey M bemg known by the AS 20 > as previously described, must store the whole princi- 

and SECIPL When the doubly encrypted ticket is ^ name 26 of the S ECIPL service 28 in ROM 42 or 

received by the cheat 20, the principal name SECIPL 15 face ible securit attacks such M those previously 

^^j^y^^^^^^gK^by^^ipr describe d. This, further, would imply that there is a 

key on the client side. Similarly, the four byte integer. sin le k whkh must be laffm b ^ instances of the 

key on the non client side ™* ^ K ke V SECIPL kernel server. THis, in turn, would imply that 

may then be transrmtted as the KRB^P_REQ en- ^ machines and administrators that „ able t /J rvice 

crypteoVpacket to the SECIPL server. Because the K2 20 S£CIpL ^ mugt be Kerberos 

key is known by the SECIPL server as well as the «- M . . . . ^ . , . 

v + r _ , . , • ■ * j • a server machines 24 and administrators. The same level 
Kerberos server from which it originated id the c i_ * i ■* i_ u * t_ * •. * 
KRB—AS— REP ticket, the SECIPL mly strip this K2 £ P £^ Mcnn * thcrefor \ be maintained for 
key off leaving the integer key known by both the client * e * ECIPL service 28 ^ ^ 
and the SECIPL. As shown at the bottom of FIG. 3B, 25 K f> e ' os server m achme (s) 24 
this four byte integer key may then be utilized to en- * e emb odunent previously described, in sum- 
crypt the kernel 70 whereupon the encrypted kernel ma ?' ±Te * were Provided. First the secret key, 

may be transmitted back to the client 20 as KRB—AP used once > md ^ own onl y t0 * e chent 1 and authentica- 

REP 74. Upon receipt by the client 20, this four byte u ° n to J^? t T a,ld subse <l uentl y presented by 

integer key may be utilized by the client to decrypt the 30 * he ?} ltn * to * he SECIPL to obtain the boot image, and 

kernel 70 to provide the desired authenticated initial fmai] y the . shared ke ^ K3 ' utlhz ed for encryption or 

program load code. In the alternative, the kernel, upon checksuming. 

transmission from the SECIPL, may be checksumed lt ^ be readily apparent that as described, the ser- 

with the checksum encoded by the integer. Whereas vice ke y K2 ' assumes a previous communication be- 

this would permit reads of the kernel since it would be 35 twcen the SECIPL and AS servers to agree on the 

unencrypted when sent from the SECIPL to the client, service key, K2, to be distributed to clients. Moreover, 

the client could nevertheless by decrypting the check- the shared key K3, assumed such a key, perhaps created 

sum transmitted from the SECIPL to the client, verify b y the client, but nevertheless transmitted previously to 

that although the kernel may have been read by others SECIPL server. In an alternate embodiment, a 

it was not tampered with inasmuch as the checksum 40 mechanism is provided to circumvent the intervention 

remained intact. or * a counterfeit server without a hardcoded name as 

Further preferred details of implementation of the previously described. Referring to FIG. 3, when the 

foregoing will now be described. One problem which is authentication server responds with the K2 ticket, 71, 

desired to be solved in any implementation of a secure 211 additional step could be inserted which would cause 

boot of a diskless workstation is to provide an architec- 45 Kerberos server to send the K2 key to the SECIPL 

ture whereby minimal modifications to existing systems server (optionally encrypted with Kl). The client, 20, 

may be made to provide this feature. A particularly could then validate the SECIPL server as being genuine 

desirable manner of implementing support for secure by requesting this K2 key from the SECIPL server. The 

IPL in a diskless workstation in accordance with the client could thereafter decrypt the K2, K3 packet re- 

invention is to provide a boot-time hook that searches 50 ceived from the Kerberos server utilizing the K2 key 

I/O for IPL code. If such code is found, it is copied into received from the SECIP1 server and thereby validate 

real memory of the client and executed. The foregoing the SECIPL server by looking for an identity between 

is a typical manner in which personal computers work the remaining K3 key and the K3 key obtained by sim- 

for example. If the diskless machine or workstation does ply decrypting with the Kl key. 

not have expansion slots allowing for additional I/O 55 While the invention has been shown and described 

adapter devices, a preferred implementation would with reference to particular embodiments thereof, it 

search the native I/O device space for a response to an will be understood by those skilled in the art that the 

IPL code-polling sequence. Devices which would give foregoing and other changes in form and detail may be 

rise to such a response may include SCSI bus, serial, and made therein without departing from the spirit and 

parallel devices, for example. This form of secure IPL 60 scope of the invention, 

architecture accordingly allows the standard diskless We claim: 

workstation to be created with minimal modifications 1. A method executed by a computer system com- 

for secure IPL thereby providing numerous benefits prised of a client and a server in a network for providing 

relating to manufacturing and distribution. However, a secure operating system comprising 

such architecture would moreover permit costs in- 65 storing a shared key at said client; 

curred in developing such a secure IPL to be recovered communicating signals across said network compris- 

only from customers requiring such a feature, e.g. when ing a request including said shared key from said 

hardware is sold which includes the IPL code, encryp- client to said server interconnected by said net- 
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work for activating said operating system at said 
client; 

authenticating said request at said server; 

communicating signals across said network compris- 
ing a response from said server to said client in 5 
response to said authenticated said request, said 
response from said server including at least a por- 
tion of said operating system; 

authenticating said at least a portion of said operating 
system at said client with said shared key; and *0 

activating said operating system at said client in re- 
sponse to said response from said server. 

2. The method of claim 1 wherein said authenticating 
said request is a precondition to said communicating 
said response. 15 

3. The method of claim 1 further including the step of 
authenticating at said client said response from said 
server. 

4. The method of claim 3 wherein said authenticating 
said response is a precondition to said activating said 20 
operating system. 

5. The method of claim 1 wherein said response from 
said server comprises said at least a portion of said oper- 
ating system encrypted prior to said communicating 
said response and decrypted prior to said activating said 
operating system. 

6. The method of claim 5 wherein said operating 
system is decrypted and encrypted by said client and 
said server, respectively. 30 

7. The method of claim 1 wherein said response fur- 
ther comprises a cryptographic checksum of said at 
least a portion of said operating system verifiable by 
said client. 

8. A method executed by a computer system for pro- 35 
viding a secure operating environment at a client sta- 
tion, comprising 

storing a service key at a secure boot server; 
generating a request for a secure boot image from said 

client to a boot server; 4^ 
receiving a response from said boot server by said 

client; 

communicating a request encoded by a key known by 
said client and an authentication server, corre- 
sponding in part to said boot server response, by 4,5 
said client to said authentication server for a token 
for said secure boot image comprised of at least 
said service key and a shared key; 

storing said shared key at said client; 

communicating said token from said authentication 50 
server to said client in response to said request; 

communicating said token from said client to said 
secure boot server; 

verifying said token with said service key at said 
secure boot server; 55 

communicating to said client from said secure boot 
server, in response to said verifying, at least a por- 
tion of an operating system authenticatable by said 
client with said shared key; 

authenticating said at last a portion of said operating 60 
system by said client with said shared key; and 

executing by said client said at least a portion of said 
operating system in response to said authenticating. 

9. The method of claim 8 wherein said response from 
said boot server includes an address of said boot server. 65 

10. The method to claim 9 wherein said response 
from said boot server further includes an address of said 
authentication server. 



11. The method of claim 10 wherein said request by 
said client to said authentication server includes a 
unique principal name of said boot server known to said 
client and to said authentication server and stored in 
non-volatile memory of said client. 

12. A method executed by a computer system includ- 
ing at least one client workstation interconnected to a 
network for providing an authenticated operating sys- 
tem at said client workstation comprising 

specifying a first key, a service key, and a shared key; 

transmitting onto said network a first request from 
said client workstation for an operating environ- 
ment; 

authenticating said first request received from said 
network with said first key; 

transmitting a token corresponding to said first key, 
said service key and said shared key onto said net- 
work, and to said client in response to said authen- 
ticating said receiving first request; 

transmitting onto said network a second request func- 
tionally related to said token from said client work- 
station for said operating environment; 

authenticating said second request received from said 
network with said service key; 

transmitting information at least partially encrypted 
with said shared key onto said network and to said 
client workstation in response to said authenticat- 
ing said received second request; 

decrypting said at least partially encrypted informa- 
tion at said client with said shared key; and 

executing said operating environment at said client 
workstation in response to said decrypting of said 
at least partially encrypted information. 

13. The method of claim 12 wherein said authenticat- 
ing said received first request is by an authorization 
server attached to said network. 

14. The method of claim 13 wherein said token is 
transmitted from said authentication server. 

15. The method of claim 13 wherein said authenticat- 
ing said received second request is by a secure initial 
program load (SECIPL) server attached to said net- 
work. 

16. The method of claim 15 wherein said at least 
partially encrypted information is transmitted from said 
SECIPL server to said client workstation. 

17. The method of claim 16 wherein said at least 
partially encrypted information comprises at least part 
of an encrypted operating system decryptable by said 
client workstation. 

18. The method of claim 16 wherein said at least 
partially encrypted information comprises a crypto- 
graphic checksum, decryptable by said client, of at least 
a part of an operating system transmitted from said 
SECIPL server to said client. 

19. A system for providing a secure operating system 
for a client in a network environment, comprising 

authentication server means interconnected to said 
network for authenticating a request from said 
client for said operating system and providing to 
said client an indicator of authenticating; 

secure program load server means interconnected to 
said network for determining said client has re- 
ceived said indicator and transmitting encrypted 
data including at least a portion of an operating 
system on said network to said client in response to 
said determining; and said network to said client in 
response to said determining; and 
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client workstation means interconnected to said net- 
work for executing said secure operating system in 
response to unencrypting of said data by said client. 

20. The system of claim 19 wherein said client work- 
station means includes means for transmitting said re- 5 
quest onto said network. 

21. The system of claim 20 wherein said client work- 
station means further includes means for receiving said 
indicator from said network. 1Q 

22. The system of claim 21 wherein said client means 
further includes means for transmitting on said network 
to said secure program load means information in re- 
sponse to. said client workstation means receiving said 
indicator, from which said determining by said secure 15 
program load means is performed. 

23. The system of claim 19 wherein said encrypted 
data is a cryptographic checksum corresponding to said 
operating system. 
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24. A system for providing a secure operating system 
for a client in a network environment, comprising 

authentication server means interconnected to said 
network for authenticating a request from said 
client for said operating system and providing to 
said client an indicator of authenticating; 

secure program load server means interconnected to 
said network for determining said client has re- 
ceived said indicator and transmitting at least a 
portion of an operating system and a cryptographic 
checksum of said portion of said operating system 
on said network to said client in response to said 
determining; and 

client workstation means interconnected to said net- 
work for executing said secure operating system in 
response to authenticating said portion of said op- 
erating system with said cryptographic checksum 
by said client. 
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